home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9359 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.2 KB
  1. Path: goanna.cs.rmit.EDU.AU!not-for-mail
  2. From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c
  4. Subject: Re: Hungarian notation - whoops!
  5. Date: 1 Mar 1996 20:34:49 +1100
  6. Organization: Comp Sci, RMIT, Melbourne, Australia
  7. Message-ID: <4h6gbp$guh@goanna.cs.rmit.EDU.AU>
  8. References: <30C40F77.53B5@swsbbs.com> <4fc157$jsf@goanna.cs.rmit.EDU.AU> <dewar.823793746@schonberg> <4fms62$c0p@goanna.cs.rmit.EDU.AU> <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca> <4g9255$74s@goanna.cs.rmit.EDU.AU> <824909942snz@genesis.demon.co.uk>
  9. NNTP-Posting-Host: goanna.cs.rmit.edu.au
  10. X-Newsreader: NN version 6.5.0 #0 (NOV)
  11.  
  12. I complain about abs(X) giving wrong answers.
  13.  
  14. Lawrence Kirby <fred@genesis.demon.co.uk> writes:
  15.  
  16. >Checking against overflow is required whatever representation is used.
  17.  
  18. In the case of unary minus and abs, this is not true.
  19. Those are the functions I was discussing.
  20.  
  21. >Once this is established using 2's complement is no worse than any other
  22. >representation.  Did you see my earlier reply in the thread on this subject?
  23.  
  24. Yes, but it was neither comfort nor assistance.
  25.  
  26. >If nothing else it seems to me that 2's complement is a big win with
  27. >regards to implementing multiple-precision arithmetic since lower order
  28. >bits of the result of most operations don't depend on the signs of the
  29. >operands or the sign of the result.
  30.  
  31. I have implemented multiple-precision arithmetic, and I must say I found
  32. 2s-complement a confounded nuisance.  What I wanted, and what I used,
  33. was arithmetic on N-bit natural numbers with overflow.  In short, what
  34. I wanted for multiple precision arithmetic was
  35.     N-bit natural + N-bit natural -> N-bit natural + carry
  36.     N-bit natural - N-bit natural -> N-bit natural + borrow
  37.     N-bit natural x N-bit natural -> 2N-bit natural
  38.     2N-bit natural (/,%) N-bit natural -> N-bit natural, N-bit natural
  39. Interpreting any of these as signed gave rise to serious complications.
  40.  
  41. Oh dear.  I'm beginning to sound like Hermann Rubin.
  42.  
  43. >>The practical consequence of this is that responsibility for ensuring that
  44. >>the input to unary minus or absolute value is in range is passed onto the
  45. >>programmer.  It is that which I am complaining about.  It doesn't make my
  46. >>life as a programmer one teeny tiny bit easier.
  47.  
  48. >It doesn't make it any harder either - see my earlier post.
  49.  
  50. I saw your earlier post all right, and I didn't agree with it.
  51. Perhaps in theory you might be right.  But in PRACTICE, it isn't true.
  52. I have, for example, seen Pascal compilers where addition, subtraction,
  53. and multiplication were checked for overflow, but unary minus, absolute
  54. value, and division, were NOT checked for overflow, because they "obviously"
  55. couldn't.  But they can.
  56.  
  57. (Against myself, I must admit that one Pascal compiler for SPARCs did check
  58. the overflow flag after multiplication, but the implementor hadn't bothered
  59. to check what the multiplication routine actually _did_:  Sun's code always
  60. cleared the overflow bit whatever happened.  Ouch!)
  61.  
  62. >>Modular arithmetic in Ada 95 *is* the ticket for portable hackery.
  63. >>Unsigned arithmetic in C is indeed defined to be modulo 2**n for some
  64. >>n, but the bounds on n are very very loose, and the price of portability
  65. >>is much programmer-inserted masking.
  66.  
  67. >Well, a small amount of masking.
  68.  
  69. Every operation except comparison needs it.  That's not a small amount.
  70.  
  71. >True, modulo arithmetic isn't useful in contexts where it simply generates
  72. >the wrong result (however it does make it easy to test for overflow after
  73. >an unsigned operation).
  74.  
  75. It depends on what you mean by easy.  There are machines where the unsigned
  76. arithmetic operations don't set the carry/borrow/overflow/whatever bit.
  77. There are others where there are minor glitches, e.g. on the M88100,
  78.     unsigned x, y;
  79.     x += y <<without overflow check>>
  80.     x += y <<with    overflow check>>
  81.     x += 1 <<without overflow check>>
  82. all take one instruction, but
  83.     x += 1 <<with   overflow check>>
  84. takes two instructions, and the integer multiply instruction delivers the
  85. bottom 32 bits with no overflow indication available at all. 
  86.  
  87. I suspect that you mean that it is easy in C using unsigned arithmetic
  88. to test for overflow by using a short sequence of instructions.  I am
  89. well aware of that, and I am also aware that it isn't easy, although C++
  90. or Ada could let you do this without cluttering up the visual appearance
  91. of the code (user-overloaded inline operators).
  92.  
  93. >Only if the code doesn't test for wrap to zero. Unsigned types make this
  94. >test very easy.
  95.  
  96. YES BUT THEY MAKE IT ******NECESSARY*******.
  97. (and in C, they don't make it any easier than signed types, in practice).
  98.  
  99. The whole point that I am making is that MY code gets cluttered up!
  100.  
  101. >>Overflows aren't the problem.  Restricted machine arithmetic is the problem.
  102.  
  103. >It depends on where you put the limit. Language support for multiple-precision
  104. >arithmetic or specified precision beyond 64 bits (or possibly 128 bits)
  105. >has some uses but they are rare across the whole spectrum of code.
  106.  
  107. I haven't been asking for multiple precision arithmetic.
  108. I haven't been asking for specified precision beyond 64 bits.
  109. (In my computing youth, I had 78 bits + sign and was happy.  Sigh.)
  110. All I keep on saying is that
  111.     - hardware arithmetic which delivers "wrong" results
  112.     - combined with compilers that don't check the warning flags
  113.       that ARE available in many architectures
  114. push a lot of implementation complexity into MY code that doesn't belong
  115. there, and I don't like it.
  116.  
  117. I am advocating Dijkstra's notion of a "Hopefully sufficiently large machine",
  118. where you write a clean program that says what you mean, and if the software
  119. and hardware combination can't do that, you certainly get told.
  120.  
  121. >>You are confusing *unaligned* access with *byte* access.  Like it or not, it
  122. >>is a fact that the machines I was talking about DID support byte access,
  123. >>DID support packed arrays of character, but did NOT support unaligned
  124. >>access.
  125.  
  126. >And there are yet other systems (e.g. Crays) which don't support byte access
  127. >but compilers can still support characters arrays where the character unit
  128. >is smaller than the machine word unit by bit twiddling tricks.
  129.  
  130. I know that.  The CDC machines Pascal ran on were just such machines.
  131. You missed the point.
  132. -- 
  133. Election time; but how to get Labor _out_ without letting Liberal _in_?
  134. Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
  135.